小白专场: Merge the incoming changes into the current branc和Rebase the current branch on top of the ... |
您所在的位置:网站首页 › merge in to current › 小白专场: Merge the incoming changes into the current branc和Rebase the current branch on top of the ... |
一 背景介绍
使用idea更新代码时,有2个选项,一个是Merge the incoming changes into the current branch, 另一个是Rebase the current branch on top of the incoming changes。由于是多人多分支开发,笔者经常用的是Rebase这个选项。也不知道为什么用这个,看着别人也是用这个,不懂为什么要用rebase,而不用merge;在后面介绍过程中,会涉及到git merge的使用,以及git rebase对应的黄金规则,优缺点等等,对于git merge的初步学习和深入理解还是很有必要的。 总之,新手用merge! 老手用rebase! 老手用rebase! 老手用rebase! merge这个命令我比较熟悉,就是合并分支,自己也经常用过。那我们就从merge介绍开始,然后在说rebase。 一般在开发过程中,具体的步骤如下(下面是一个简单说明): 1 下载项目代码 git clone xxxx 2 新建一个自己的分支(dev) git checkout -b dev 3 然后在自己本地进行开发测试 4 现在需要合并团队的最新代码(默认在master上), 下面命令是把master的代码合并到dev上,如果有冲突就解决冲突。 git merge master 5 最后git push dev, 执行MR,即执行合并请求,master分支主人同意后,你的更新代码就上去了。 Merge the incoming changes into the current branch: select this option to perform merge during the update. This is equivalent to running git fetch and then git merge, or git pull --no-rebase. 以上知识了解后,言归正传;下面开始正式介绍: 现在你在Feature分支,其他团队人员在main分支上进行开发,他们也会进行代码更新和commit等等操作。现在你开始merge main. 这个坏处比较难理解,笔者用实际例子说明:现在A项目有7个分支,每个分支的历史本来应该是不同的,因为不同的人在不同分支。 但是现在,项目历史特别乱,多个分支历史互相交叠,每个分支上历史基本上都是一样的(这就是merge的坏处): 再来说一下rebase, 这个命令会始终把你最新的修改放到最前头。比如你对主branch进行rebase以后, 你的所有修改就会在主branch当前所有的修改之前。你会更有信心保证你的代码运行畅通无阻。通过你自己的测试以后, 你就可以放心的把代码合并到主的branch里面了。 三 Rebase the current branch on top of the incoming changes关于git rebase,首先要知道的是,它解决的是与git merge相同的问题。这两个命令的设计目的都是将一个分支的更改合并到另一个分支——它们只是采用了不同的方式。 1 切换到feature分支 git checkout feature 2 合并main分支内容到feature git rebase main Rebase the current branch on top of the incoming changes: select this option to perform rebase during the update. This is equivalent to running git fetch and then git rebase, or git pull --rebase (all local commits will be put on top of the updated upstream head).
下面是关于如何平衡安全性和可追踪行介绍: there are two trade-offs for this pristine commit history: safety and traceability. If you don’t follow the Golden Rule of Rebasing, re-writing project history can be potentially catastrophic for your collaboration workflow. And, less importantly, rebasing loses the context provided by a merge commit—you can’t see when upstream changes were incorporated into the feature.(个人理解:使用rebase命令会合并其他分支的历史进入到feature分支,失去了合并前的上下文信息,可能会带来潜在的灾难,因为你不知道合并前,main分支的修改到底做了什么,因为一些信息被合并了(缩减了提交历史)) 小节: 当我们开发一个功能时,可能会在本地有无数次commit,而实际上,你只想master分支上显示一次提交记录就好了,其他的提交记录并不想保留在你的master分支上,那么使用rebase吧,rebase可以将本地多次的commit合并成一个commit,还可以修改commit的描述等 四 rebase使用的黄金规则The Golden Rule of Rebasing,即什么时候适合用rebase The golden rule of git rebase is to never use it on public branches. 不要使用rebase 命令在公共分支。以下面这个图说明: 参考文章 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |